1. Technical Field
The disclosure relates to interconnection techniques.
The disclosure has been developed with attention paid to its possible application to so-called Systems-on-Chip (SoCs).
Embodiments include applications of a consumer type (digital home video, mobile and multimedia applications).
2. Description of the Related Art
In the production of integrated circuits, especially of particularly complex products of the System-on-Chip (SoC) type, it is common practice, for example, for reducing time-to-market, to use, or rather re-use, already existing IP (Intellectual Property) modules. This practice also takes into account performance improvements and new functions and leads to devising rather heterogeneous multi-protocol systems, such as to incorporate IPs of various nature and origin, for example both “external” IPs and IPs developed in house.
Designers are hence inclined to integrate advanced components (for example, CPUs of an ARM type based upon the AMBA protocol) made available by different sources. This situation, concomitantly with the desire to limit the development and production costs, leads to re-use of IP modules developed previously, giving rise to multi-protocol solutions such as to incorporate different elements operating on the basis of different communication technologies.
In the presence of transactions of a request/response type, there may hence arise the desire to get different protocols to interact with one another. In the case of protocols that do not prove mutually compatible, it is possible to resort to the solution of storing at a local level the information that cannot be converted. Thus, the response transactions can be reconstructed according to the original protocol.
A situation of the above type is represented schematically in FIG. 1, where the reference numbers 10 and 20 designate two circuit modules of the type commonly referred to as “islands.” The first island operates according to a first protocol, here referred to as protocol X, whilst the second island operates with a second protocol, here referred to as protocol Y.
The reference number 30 designates a module that is able to handle the request transactions (Req) and the response transactions (Rsp) by resorting to a conversion queue 32.
A solution of this type requires storing in the module 30, functioning as bridge, further information on all the information that is to be conveyed between the modules 10 and 20.
If it is possible to expect a determined order, in the sense that the responses are presented in the same order as the requests, the queue 32 can assume the appearance of a queue of a FIFO (First-In First-Out) type. There may, however, arise situations in which, in the communications between different modules (it will be appreciated that the reference to two islands 10, 20 is an example in so far as these modules can be present in a larger number), it is not expected that the response transactions follow the same order as the request transactions.
Such a situation (commonly referred to as OOO, i.e., Out-Of-Order) can arise in the case of high-performance CPUs. The capacity of handling OOO situations can represent in any case a point of advantage for the IPs comprised in the circuit; it is hence desirable for this possibility to be allowed.
To handle situations of an OOO type it is possible to resort to solutions that enable, within the queue 32, search operations to be carried out in order to reconstruct original information. This results, however, in considerable limitations in terms of clock frequency and of “overheads” as regards the occupation of area on silicon.
FIG. 2 is a schematic illustration of a solution that is able to handle situations of an OOO type. Known as Content-Addressable Memory (CAM), this is a solution that can be used also for implementing cache memories in processor systems.
The CAM architecture acts between a module or island 10 operating with a protocol X and a module or island 20 operating with a protocol Y with a queue mechanism in which each position or location in the queue 32 comprises two fields, designated respectively as ELEM and ID. The first field (ELEM1, ELEM2, . . . , ELEMn, where n is the “depth” of the queue) is used for storing the information regarding the transaction that cannot be converted, whilst the second field (ID1, ID2, . . . , IDn) is used as a key and contains a transaction identifier. The number n of elements comprised in the queue 32 identifies the number of transactions that may be pending at a given instant of time.
The operations of reading and writing in the queue are managed via normal read and write pointers generated by respective generators 321 (read pointers) and 322 (write pointers).
The module 30 illustrated in FIG. 2 “dialogues” with the protocol X and with the protocol Y on the basis of interface lines of which the ones designated by REQ and RSP refer to the functions of interface of the request transactions and response transactions (data-control signals).
The lines designated by ID carry a signal/information that is to enable non-ambiguous identification of the transactions (or packets) in the system by resorting in general to a union between a packet/transaction identifier and a source identifier. This information is available in general for any protocol, and the signal designated by R_ID, used for associating the responses to the requests, can constitute a replica of the information ID.
The generator of the read pointers is driven by respective blocks 323 sensitive to the identifiers ID1, ID2, ID3, IDn and to the information available on the line R_ID coming from the protocol Y. In order to find in the queue 32 the information used for reconstructing the response transactions, the CAM architecture of FIG. 2 hence implements a mechanism of control/comparison in parallel between the information R_ID coming from the module 20 (protocol Y) and all the indicators ID in the queue 32. The signal ID can hence result from the logical union of the source identifier ID and of the transaction identifier ID.
Since each identifier can comprise a certain number of bits (for example, from ten to fifteen), the search mechanism described is somewhat burdensome both in terms of circuit complexity and as a result of the negative effects on the speed of the module. The choice of recourse to this type of architecture for interfacing different protocols is somewhat penalizing in terms of requirements of area on silicon and of limitation of the clock frequency.